In the previous version of parcels, particleset.execute() overshoots the
particle trajectories by exactly one time step while leading to repeated
initial condition output lagged by exactly one time step. This leads to
an inconsistency in the actual particle positions and those written to
files

In this updated approach, when an outputfile is provided, we write the
initial condition to file before the time loop. Then, inside the time
loop, the kernels are executed with particle position updated
immediately after all other kernels and just before file IO. This
corrects the inconsistency in the actual and reported time levels for
each particle state in the output.

Unfortunately this breaks a number of tests. The unit tests are checking
for incorrect values (lagged by exactly one time loop iteration..)

…ate after user kernels

This removes the `PositionUpdate` kernel from the list of kernels. This
change was made to fix `funcname` polution if the `test_kernel_merging`,
`test_kernel_from_list`, and `test_metadata`.

With the correction in place, the particle positions are now obtained by
1 less call to positionupdate (correctly); the values in the test output
for validation were based off the wrong number of iterations due to the
fenceposting bug we're trying to address.

…ion time

With the fence posting bugfix in place, the particleset execute call
updates the position once; previously, this happened twice (this was the
bug). This test failed because the particle didn't go out of bounds with
a single position update. Semantically, setting the runtime to 2 days,
achieved what was intended here (to get the particle out of bounds)